Module 13 Spring 2006 closure
Compiled by Greg Kinney

CLEAREST ITEMS

• I found this two last chapter interesting and found the pages 602 and 603 especially interesting, giving a good review over what a evaluation report should include.

• [The most helpful item from the module was]: Better definition of what an audit is. I believe most people think about an IRS audit when they here audit. The descriptions of the different types of audits and their purposes was new and informative.

• Project termination was interesting to me as I have never been involved in this process. My background has been either construction or environmental work. In construction work myself and the projects PM have always moved on to the next job or to estimating and bidding something new. The environmental work always requires a precisely defined final report that is usually written by the PM but not really looked at as a termination process. The final report of an environmental project could easily be considered the termination or the project history document.

• This module was a very clear module in my opinion.  I would have to say that chapter 13 was more clear than chapter 12.  In other words, the information provided on project termination seemed to be quite clear.  There was plenty of information and description given about each of the termination methods including extinction, addition, integration and starvation.  The role and responsibility of the project manager was also explained well as far as how he/she deals with the project and team members during the termination period.   Last but not least, the decision when to terminate a project was also covered in sufficient detail as well as the process of implementing a termination plan.  All in all, I was pleased with chapter 13 and felt it was very clear.

• In these final chapters of the course, the importance of both the audit and closeout process have become evident. Effective audits may provide important data regarding the success, or lack thereof, of a particular project. Unfortunately, it is often difficult to perform an accurate audit due to factors such as lack of trust of the project team and their reluctance to share pertinent information with auditors, especially regarding failures. In this case, it may be difficult to avoid the causes of the demise on future projects.

• Termination by murder was the easiest thing to grasp; a clear and sudden end of the project.

• Really I had no idea there were this many ways to end a project.  I just assumed they all ended like construction projects.  I enjoyed reading about addition and integration as a means to terminate a project.

MUDDIEST ITEMS

• Comment:  Governmental organizations appear to have relatively structured project closeout procedures. However, I have rarely witnessed an actual project termination on the contractor side that includes more than just the completion of contract requirements required for final payment. Are there any regulations governing the requirement of non-accounting specific audits? 

Instructor’s reply:  If I may rephrase it a little, I understand the question to be whether there are non-financial records that contractors must retain after execution of a government project, which might be subject to a post-project governmental audit.

The answer is probably case-specific and best explored by contract lawyers.  What I’ll try to do is give you my limited understanding, with the caveat that legal questions must always be referred to counsel.  (I’m lucky because I have in-house counsel at home.  My wife is an attorney and former district court judge, and she helped me with this.) 

First, warranty-related documentation should always be retained per the terms of the contract.  Aside from that, my understanding is that when the owner accepts a project as complete, it presumptively means just that.  In a theoretical sense, therefore, the contractor has freedom to expunge any records except for those that may be required for legal reasons (which would include copies of final turnover and acceptance documentation, tax related documents, etc.).  That said, it would be imprudent to aggressively destroy all records not explicitly required.  While the owner agency may have accepted a project as complete, if some hidden defect is later discovered, the owner may then file suit against the contractor.  There may be allegations of quality issues or some form of negligence or wrongdoing.  Whatever the cause, if you don’t have some record of what you did, you will be at a severe disadvantage.

As for auditing authority of government agencies, I’ll again speak, but only in the capacity of longtime government observer and not as a regulatory affairs expert.  The government has broad authority to audit performance and compliance, in addition to finances, as long as the audit is focused on something that can be reasonably be construed as having some governmental jurisdiction.  They can and do audit federal contractors; in the case of some defense contractors, their performance audits have resulted in heavy fines and even prison sentences.  To give you an idea of their broad scope, the Government Accountability Office (GAO) has conducted several major or minor audits on the Trans-Alaska Pipeline System.  Alyeska Pipeline has very few contracts with governmental agencies, but perhaps the most important contract at all is the Agreement and Grant of Right of Way between the TAPS owners and the state and federal government.  This agreement carried with it performance stipulations, which is ultimately what gives them the right to audit.  Major examples of their audits have included security on the pipeline, and maintenance and operations practices.

Your observation about the difference between governmental and contractor termination procedures is interesting and deserves some discussion.  Owner agencies (governmental or otherwise) and contractors naturally have different closeout requirements.  The contractor’s concern is execution of the project.  The owner agency had an interest in that, too, but is now concerned with the end product.  Therefore, closeout for the owner is going to involve all the financial and quality pieces (punchlists, functional checkouts, etc.) plus O&M documentation, procedures, etc.  This requires a very structured closeout process, or the process will become erratic at best.  Contractors, on the other hand, do not have product ownership, so their termination work will consist of punchlist work, billings, final accounting, reassignment and termination of personnel, and selection of records to retain (those legally required and those electively retained for future reference and use).

• Comment:  What must be difficult for companies is to find out when to cut off a project if it is gliding away from company goals and needs. Is this mainly PM’s job to find out when to terminate or is the senior management as much responsible?

Instructor’s reply:  No, it is definitely not the PM’s job to look for whether to terminate a job based on failure to match the company’s goals and needs.  The PM’s job is to get the project done, meeting the so-called triple constraints of scope, schedule and budget.  The PM is focused exclusively on that goal, and in fact is in a very poor position to see the big picture of whether organizational goals no longer require completion of the job. 

What should also be recognized is that the PM is a stakeholder in the project.  His or her livelihood is now tied to the project.  We can’t expect objectivity under those circumstances.  Not to be too political, but we have a current (May 2006) example of how a project organization actually promotes their project in the face of hostile fire.  I am referring to ads run in the Anchorage Daily News by the project organization, the Knik Arm Bridge and Toll Authority, which is obviously interested in assuring their project doesn’t get killed.  I am only pointing this out because it has to be others – in this case through a political process – to determine whether the state really needs this project.  You can’t depend on the project managers for that.

• Comment:  [The least helpful item from the module was]: Termination of the project. It seemed that they suggested that all projects are difficult to terminate. For me, it would seem that some projects when completed successfully would not have all this difficulty that was suggested by the authors. Are all projects really this difficult?

Instructor’s reply:  It all depends on the complexity of the project and the requirements.  The authors assumed high end projects, which are the most difficult, for purposes.  I think they recognize that minor-modification projects (on the order of $10K) would not require the same level of effort as major projects (on the order of $100MM, say).

• Comment:  The section on measurement is still a little unclear to me. It is so often that the exchange of information between the PM and team members and administration that we are not talking apples and oranges. Several aspects of a project can be easily measured but there others we just can’t put in the form of spreadsheets or accountant language. A far more difficult task is deciding what revenues should be assigned to the project or which project. This can be difficult in the organization I work with because of how much the projects share resources such as heavy equipment. We also have several PMs that would like to take the credit for different accomplishments but have no intention to do any maintenance or up keep of the equipment used. This cost ends up somewhere and usually not charged to the project that put the hours on the equipment. 

Instructor’s reply:  You’ve nailed it.  In organizations like yours or mine, there is a lot going on, different groups with different missions, and lots of functional bergs.  The Baseline maintenance forces may end up subsidizing projects, and sometimes vice versa.  Does it really “all come out in the wash”?  It’s impossible to say.  This is why the authors stress that the seemingly simple task of getting good measurements of certain project attributes may not be so straightforward after all.

• Comment:  The muddiest or least clear part of this module was chapter 12.  Chapter 12 dealt with the auditing process.  The textbook covered the auditing process in depth.  The detail was great but when I finished reading the chapter I had some unanswered questions.  Does the auditing process have to happen in order to resolve certain issues or can the issues be resolved at a round table type meeting?  To what extent does the customer have to be involved in the auditing process?  Why wouldn’t a project audit be a good idea for all project just to ensure the accuracy and truth of the details?  In all honesty, the textbook covered most of the details regarding the auditing process.  I just felt like chapter 12 was a little light in comparison to chapter 13 in terms of clarity and explanation. 

Instructor’s reply:  I’ll try to answer this.  On your first question, hopefully it is clear that audits can be undertaken for several reasons.  One of them is for cause, which will happen if a project entity (the project team or a contractor) is suspected of having a systematically flawed process or perhaps is suspected of dishonesty.  In this case, the agency commissioning the audit has reason to think that the issues really can’t be addressed at a meeting.  Another reason may to randomly sample a project process in order to determine whether project execution processes are being adhered to.  This is more an issue of general quality assurance.

On the second question, the customer or client is involved if the audit is undertaken at his or her request.  Otherwise, it may be an internal audit, or perhaps a governmental audit (in this case, the government assumed not to be the client).  In these latter kinds of audits, the customer may become a witness and may be interviewed.  But the involvement really depends on the purpose of the audit (if it’s a QA audit, they really shouldn’t be involved).

Finally, should auditing be done for all projects?  No – it is too time consuming and will not provide high value.  QA audits on a sampling basis should provide a picture as to whether the general processes are followed.

• Comment:  I thought question 8 on the quiz was a little muddy or confusing.  The question read, “A good time to terminate a project is when the project no longer agrees with the goals or needs of the firm.”  My first reaction was, TRUE.  But as I read paragraph 1 on page 637 I began to think otherwise.  Should an organization abandon a project that it has invested in (sunk cost)?  Or should the organization see it through based upon initial decisions?

Instructor’s reply:  Most economists – not all, but most – will argue that sunk costs are not relevant, only future costs (and potential future revenue streams based on completing the investment) are.  If you have spent 60% of your budget, and you find out that it’s almost certain that the project will produce no return even on the 40% remaining (much less the amount already spent), does it make sense to see it through?  It is probably more rational to simply cut your losses.  That’s an example – an economics based example – of a good time to terminate a project.   There are many other examples that are less quantitative and more strategic or personality based.  Either way, if a project can no longer be supported by the organization, it is time for the executives to terminate it.

• Comment:  The whole concept of auditing and termination was new to me and it was hard to swallow everything. So I rather ask an question about something else. The book has mentioned several times something called Six Sigma. I am not familiar with that. Hence I wonder what it is. 

Instructor’s reply:  Six Sigma is a quality process which was originated in Motorola in the 1980s.  The name comes from the world of statistical process control (SPC), and SPC is used in the Six Sigma process methodology (six sigma equates to 3.4 defects per million opportunities).  However, the process overall is management oriented.  Its stated goal is to eliminate defects by redesigning processes so that the defects can never occur in the first place.  Though Motorola originated this, the all-time champion of Six Sigma was Jack Welch, former CEO of GE.  There are numerous books out there on the subject, such as “Six Sigma” by Mikel Harry and Richard Schroeder.  Welch’s autobiography “Jack: Straight from the Gut” (2001) also discusses GE’s adoption of Six Sigma at length.

• Comment:  I felt this chapter was clear and understandable for the most part.  I guess Termination by addition was hard to believe and I would have liked more ‘real world’ examples.

Instructor’s reply:  They didn’t do a great job explaining this.  An example I can think of is about 25 years ago when I was working in Homer, the city was building a new ice facility for fish processing.  The project was constructed and several of the technicians who helped to construct it were hired to operate and maintain it.  The facility was effectively added to the Port and Harbor infrastructure as a manageable entity.